Integrated circuits and chips have become increasingly complex with the speed and capacity of chips significantly increasing about every eighteen months because of advances in design software, fabrication technology, semiconductor materials, and chip design. The increased density of transistors per square centimeter and more sophisticated clocking schemes required to effectively utilize all of those transistors, however, make it increasingly difficult to create minimal yet sufficient clock related design constraints. The proper specification of these constraints is essential in order to ensure that the circuits perform as desired. Unanticipated and sometimes subtle interactions between different clocks and the circuits that use them can lead to issues in design closure as well as the correct operation of the circuits themselves. These difficulties increase the expense and risk of designing and fabricating chips whether they be platform ASICs, ASICs, FPGAs, or fully custom semiconductor products. Indeed, despite the complexity and expense, the demand for custom-designed integrated circuits increases. A key problem in the delivery of these circuits is that of design closure, and a key component of design closure is creating the constraints for the tools that perform design closure, and among the most important constraints are the clocking constraints. The clocking constraints, moreover, should be just enough and no more, i.e., correct and minimal. Every unnecessary constraint burdens the design system with unnecessary restrictions that are harder to resolve and close. At the same time, however, any missing clocking constraints can result in circuit failure.
Clock constraints are a key constituent of logical and physical optimization and static timing analysis. In a synchronous design, data is “launched” from a storage element based on the transition of a clock and data is captured in a storage element based on the transition of a clock. The launch and capture clock may be the same clock or may be different clocks. A set of minimal clock constraints describe the nature of the interaction in either case. For example if a clock has a ten nanosecond period and the launch and capture clock are shared then the time available to perform an operation on the data is ten nanoseconds less aggregate clock uncertainty. There are many factors that affect the aggregated clock uncertainty but the net effect of the sum of all the uncertainties is a reduction in the amount of time a circuit has to complete its operation on the data in question. If the circuit cannot deliver the data from one stage to the next during the allotted time then the circuit does not operate as intended, the data is lost, and the cost for the design, development, and production of the semiconductor product is wasted. This is a simple example. There are more complex scenarios but the net effect is the same: if the data fails to propagate correctly, the circuit effectively fails. If the design closure tools do not have a correct clocking constraints, it is very likely that failing circuits will be produced.
At the same time creating overly restrictive constraints often results in a case where the design tools cannot close the design without significant rework that is also time consuming and expensive. If there were only one or two clocks in a semiconductor product, the problem would be simple but today chips such as those referred to as “systems-on-a-chip” may have hundreds of clocks with a great many clock domain crossings. In addition the logic involved in domain crossing may serve more than one function and performance level. The result is a complex collection of clocks and clock interactions that is very difficult to unknot. Manually unknotting these interactions is difficult, time consuming and error prone.
In the design, a clock will clock memory elements within part of the design. The section of logic driven by a clock is called a clock domain. The interface boundaries between clock domains are called the clock domain crossings (CDC). When data passes from one clock domain to another, key questions need to be answered. Do the clocks involved share a common source clock somewhere in the system; for example, do the clocks share the same phase locked loop (PLL) or primary input/output (I/O) as a clock source? If so, must specific phase relationships between the common source and/or the clocks be maintained? If not, then does an asynchronous domain crossing circuit that offers appropriate predictability need to be placed at the interface of the clock domain crossing?
The answers to these kinds of questions have direct implications for design closure and design functionality. In the case of an asynchronous domain crossing design, closure is more relaxed. This relaxation, however, comes at a price, typically at the expense of logical signal/data latency. This occurs because there is no way to know which exact cycle information will cross an interface. This may result in cycles of delay. So while design closure is easier, the efficiency of the logic is reduced which is often a critical factor in many interfaces. On the other hand, when clocks are related by definition, design closure is more difficult and the optimization tools have a much harder problem to solve. Interface latency, however, can be minimized given the nature of the relationship and, indeed, should be faster than the case where the clocks are not related. As the number of relationships increase, the degree of difficulty in solving the problem increases significantly because solving one case may actually harm another case.
Today the creation of these constraints is an intensive, slow, iterative process requiring much analysis; the process is very error prone. The technique usually involves generating a trial set of constraints, trying these constraints in the closure tools, and then analyzing the results. The constraints are then modified and the cycle repeats. The run time for creating and analyzing the results can range from hours to days and the process may need to be repeated many many times. In addition it is very possible to introduce an error that is undetectable until after the silicon has been fabricated, such as when a false path is set where it shouldn't be or when an asynchronous domain fails to have a correct domain crossing circuit. The result is a set of paths that pass through the design closure process but fail to function as intended. Such errors typically require a “respin” of the chip that sends a chip back to the drawing board, requiring new masks and costing millions. So, in the end, both too many and too few clocking constraints can cause failure. In addition these constraints are created over time through an iterative process, so it is possible to have the clocking constraints be correct for some period of time and then later be incorrect because of logic changes. So there is also regular maintenance aspect as well. Keeping track of all the possibilities and changes can be daunting, especially if there are hundreds of clocks in the design.
There is thus a need in the industry to automate and streamline the process of finding and calculating the proper minimal set of clocking constraints across an integrated circuit product. In addition, developers need a tool that can design these clocking constraints solutions and be compatible with a myriad of electronic design automation (EDA) tools.